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On Safety Properties and Their Monitoring 


Grigore ROSU! 


Abstract 


This paper addresses the problem of runtime verification from a 
foundational perspective, answering questions like “Is there a consen- 
sus among the various definitions of a safety property?” (Answer: 
Yes), “How many safety properties exist?” (Answer: As many as 
real numbers), “How difficult is the problem of monitoring a safety 
property?” (Answer: Arbitrarily complex), “Is there any formalism 
that can express all safety properties?” (Answer: No), etc. Various 
definitions of safety properties as sets of execution traces have been 
proposed in the literature, some over finite traces, others over infinite 
traces, yet others over both finite and infinite traces. By employing 
cardinality arguments and a novel notion of persistence, this paper 
first establishes the existence of bijective correspondences between the 
various notions of safety property. It then shows that safety properties 
can be characterized as “always past” properties. Finally, it proposes 
a general notion of monitor, which allows to show that safety proper- 
ties correspond precisely to the monitorable properties, and then to 
establish that monitoring a safety property is arbitrarily hard. 
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1 Introduction 


A safety property is a behavioral property which, once violated, cannot be 
satisfied anymore. For example, a property “always x > 0” is violated when 
x <0 is observed for the first time; this safety property remains violated 
even though eventually z > 0 might hold. That means that one can identify 
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each safety property with a set of “bad” finite execution traces, with the 
intuition that once one of those is reached the safety property is violated. 


There are several apparently different ways to formalize safety. Perhaps 
the most immediate one is to complement the “bad traces” above and thus 
to define a safety property as a prefix-closed property over finite traces 
(containing the “good traces”) — by “property” in this paper we mean a set 
of finite or infinite traces. Inspired by Lamport [9], Alpern and Schneider 
[4] define safety properties over infinite traces as ones with the property 
that if an infinite trace is unacceptable then there must be some finite 
prefix of it which is already unacceptable, in the sense that there is no 
acceptable infinite completion of it. Is there any relationship between these 
two definitions of safety? We show rather indirectly that there is, by showing 
that their corresponding sets of safety properties have the cardinal c of the 
continuum (i.e., the cardinal of R, the set of real numbers), so there exists 
some bijective mapping between the two. Unfortunately, the existence of 
such a bijection is as little informative as the existence of a bijection between 
the real numbers and the irrational numbers. To capture the relationship 
between finite- and infinite-trace safety properties in a meaningful way, we 
introduce a subset of finite-trace safety properties, called persistent, and then 
construct an explicit bijection between that subset and the infinite-trace 
safety properties. Interestingly, over finite traces there are as many safety 
properties as unrestricted properties (finite-traces are enumerable and P(N) 
is in bijection with R), while over infinite traces there are c safety properties 
versus 2° unrestricted properties (infinite traces are in bijection with R). 


It is also common to define safety properties as properties over both 
finite and infinite traces, the intuition for the finite traces being that of 
unfinished computations. For example, Lamport [10] extends the notion 
of infinite-trace safety properties to properties over both finite and infinite 
traces, while Schneider et al. [14, 7] give an alternative definition of safety 
over finite and infinite traces, called “execution monitoring”. One immediate 
technical advantage of allowing both finite and infinite traces is that one can 
define prefix-closed properties. We indirectly show that prefix-closeness is 
not a sufficient condition to define safety properties when infinite traces are 
also allowed, by showing that there are 2° prefix-closed properties versus, as 
expected, “only” c safety properties. 


Another common way to specify safety properties is as “always past” 
properties, that is, as properties containing only words whose finite prefixes 
satisfy a given property. If P is a property on finite prefixes, then we write 
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P for the “always P” safety property containing the words with prefixes 
in P. We show that specifying safety properties as “always past” properties 
is fully justified by showing that, for each of the three types of traces (finite, 
infinite, and both), the “always past” properties are precisely the safety 
properties as defined above. It is common to specify P using some logical 
formalism, for example past time linear temporal logic (past LTL) [11]; for 
example, one can specify “a before b” in past LTL as the formula b > oa. 

The problem of monitoring safety properties is also investigated in this 
paper. Since there are as many safety properties as real numbers, it is not 
unexpected that some of them can be very hard to monitor. We show that 
the problem of monitoring a safety property is arbitrarily hard, by showing 
that it reduces to deciding membership of natural numbers to a set of natural 
numbers. In particular, we can associate a safety property to any degree in 
the arithmetic hierarchy as well as to any complexity class in the decidable 
universe, whose monitoring is as hard as that degree or complexity class. 

This paper makes three novel contributions, two technical and another 
pedagogical. On the technical side, it first introduces the notion of a persistent 
safety property, which appears to be the right finite-trace correspondent of 
an infinite-trace safety property, and uses it to show the cardinal equivalence 
of the various notions of safety property encountered in the literature. Also 
on the technical side, it rigorously defines the problem of monitoring a safety 
property, and it shows that it can be arbitrarily hard. On the pedagogical 
side, this paper offers the first comprehensive study and uniform presentation 
of safety properties and of their monitoring. 


2 Preliminaries and Notations 


Let N denote the set of natural numbers including 0 but excluding the infinity 
symbol co and let N, denote the set NU {oo}. Also, let Q denote the set of 
rational numbers and R the set of real numbers; as for natural numbers, the 
“oo” subscript can also be added to Q and R for the corresponding extensions 
of these sets. QT and R™ denote the sets of strictly positive (0 not included) 
rational and real numbers, respectively. 

We fix a set © of elements called events or states. We call words in %* 
finite traces and those in 1” infinite traces. If u€ U* US” then u; is the i-th 
state or event that appears in u. We call finite-trace properties sets P C &* 
of finite traces, infinite-trace properties sets P C %” of infinite traces, and 
just properties sets P C &* U &” of finite or infinite traces. If the finite or 
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infinite aspect of traces is understood from context, then we may call any 
of the types or properties above just properties. We may write P(w) for a 
property P and a (finite or infinite) trace w whenever w € P. Traces and 
properties are more commonly called words and languages, respectively, in 
the literature; we prefer to call them traces and properties to better reflect 
the intuition that our target application is monitoring and system observance, 
not formal languages. We take, however, the liberty to also call them words 
and languages whenever that terminology seems more appropriate. 


In some cases states can be simply identified with their names, or labels, 
and specifications of properties on traces may just refer to those labels. For 
example, the regular expression (s; - $2)* specifies all those finite traces 
starting with state s; and in which states s; and s2 alternate. In other cases, 
one can think of states as sets of atomic predicates, that is, predicates that 
hold in those states: if s is a state and a is an atomic predicate, then we 
say that a(s) is true iff a “holds” in s; thus, if all it matters with respect 
to states is which predicates hold and which do not hold in each state, 
then states can be faithfully identified with sets of predicates. We prefer to 
stay loose with respect to what “holds” means, because, depending on the 
context, it can mean anything. In conventional software situations, atomic 
predicates can be: boolean expressions over variables of the program, their 
satisfaction being decided by evaluating them in the current state of the 
program; or whether a function is being called or returned from; or whether 
a particular variable is being written to; or whether a particular lock is 
being held by a particular thread; and so on. In the presence of atomic 
predicates, specifications of properties on traces typically only refer to the 
atomic predicates. For example, the property “always a before 6”, that is, 
those traces containing no state in which b holds that is not preceded by some 
state in which a holds (for example, a can stand for “authentication” and b 
for “resource access”), can be expressed in LTL as the formula O(b > ¢a). 


Let us recall some basic notions from formal languages, temporarily 
using the consecrated terminology of “words” and “languages” instead of 
traces and properties. For an alphabet ©, let Ly be the set of languages over 
u, ie., the powerset P(h*). By abuse of language and notation, let be the 
empty language {} and ¢ the language containing only the empty word, {e}. 
If Ly, Lz € Ly then Ly - Le is the language {a a2 | ay € Li and ag € Lp}. 
Note that L-@=@-L=@and L-e=e-L=L. If L € L»y then L* is 
{a1a2-+-An|n>0 and a1,a2,...,Qn € L} and aL is &* — L. 


We next recall some notions related to cardinality. If A is any set, we 
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let |A| denote the cardinal of A, which expresses the size of A. When A is 
finite, |A| is precisely the number of elements of A and we call it a finite 
cardinal. Infinite sets can have different cardinals, called transfinite or even 
infinite. For example, natural numbers N have the cardinal Xo (pronounced 
“aleph zero”) and real numbers R have the cardinal c, also called the cardinal 
of the continuum. Two sets A and B are said to have the same cardinal, 
written |A| = |B|, iff there is some bijective mapping between the two. We 
write |A| < |B] iff there is some injective mapping from A to B. 


The famous Cantor-Bernstein-Schroeder theorem states that if |A| < |B| 
and |B| < |A| then |A| = |B]. In other words, to show that there is some 
bijection between sets A and B, it suffices to find an injection from A to B 
and an injection from B to A. The two injections need not be bijections. For 
example, the inclusion of the interval (0,1) in R* is obviously an injection, 
so |(0,1)| < |R*|. On the other hand, the function « ~* x/(2x2 +1) from 
Rt to (0,1) (in fact its codomain is the interval (0,1/2)) is also injective, 
so |R*| < |(0,1)|. Neither of the two injective functions is bijective, yet by 
the Cantor-Bernstein-Schroeder theorem there is some bijection between 
(0,1) and R*, that is, |(0,1)| = |IR*|. We will use this theorem to relate the 
various types of safety properties; for example, we will show that there is an 
injective function from safety properties over finite traces to safety properties 
over infinite traces and another injective function in the opposite direction. 
Unfortunately, the Cantor-Bernstein-Schroeder theorem is existential: it 
only says that some bijection exists between the two sets, but it does not 
give us an explicit bijection. Since the visualization of a concrete bijection 
between different sets of safety properties can be very meaningful, we will 
avoid using the Cantor-Bernstein-Schroeder theorem when we can find an 
explicit bijection between two sets of safety properties. 


If A is a set of cardinal a, then 2° is the cardinal of P(A), the power 
set of A (the set of subsets of A). It is known that 2*° = c, that is, there 
are as many sets of natural numbers as real numbers. The famous, still 
unanswered continuum hypothesis, states that there is no set whose size is 
strictly between No and c; more generally, it states that, for any transfinite 
cardinal a, there is no proper cardinal between a and 2°. If A and B are 
infinite sets, then |A| + |B] and |A|-|B| are the cardinals of the sets AU B 
and A x B, respectively. An important property of transfinite cardinals is 
that of absorption — the larger cardinal absorbs the smaller one: if @ and 
G8 are transfinite cardinals such that a < 6, thena+6=a-$ = £; in 
particular, c- 2° = 2°. Besides sets of natural numbers, there are several 
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other important sets that have cardinal c: streams (i.e., infinite sequences) 
of booleans, streams of reals, non-empty closed or open intervals of reals, as 
well as the sets of all open or closed sets of reals, respectively. 

For our purposes, if © is an enumerable set of states, then %* is also 
enumerable, so it has cardinal No. Also, if || < c, in particular if it is finite, 
then ” has the cardinal c, because it is equivalent to streams of states. We 
can then immediately infer that the set of finite-trace properties over © has 
cardinal 280 = c¢, while the set of infinite-trace properties has cardinal 2°. 


3 Safety Properties 


Intuitively, a safety property of a system is one stating that the system 
cannot “go wrong”, or, as Lamport [9] put it, that the “bad thing” never 
happens. In other words, in order for a system to violate a safety property, it 
should eventually “go wrong” or the “bad thing” should eventually happen. 
There is a very strong relationship between safety properties and runtime 
monitoring: if a safety property is violated by a running system, then the 
violation should happen during the execution of the system, in a finite 
amount of time, so a monitor for that property observing the running system 
should be able to detect the violation; an additional point in the favor of 
monitoring is that, if a system violates a safety property at some moment 
during its execution, then there is no way for the system to continue its 
execution to eventually satisfy the property, so a monitor need not wait for 
a better future once it detects a bad present/past. 

State properties or assertions that need only the current state of the 
running system to check whether they are violated or not, such as “no 
division by 0”, or “a positive”, or no deadlock, are common safety properties; 
once violated, one can stop the computation or take corrective measures. 
However, there are also interesting safety properties that involve more than 
one state of the system, such as “if one uses resource x then one must have 
authenticated at some moment in the past”, or “any start of a process must 
be followed by a stop within 10 units of time”, or “take command from 
user only if the user has logged in at some moment in the past and has 
not logged out since then”, etc. Needless to say that the atomic events, or 
states, which form execution traces on which safety properties are defined, 
can be quite abstract: not all the details of a system execution are relevant 
for the particular safety property of interest. In the context of monitoring, 
these relevant events or states can be extracted by means of appropriate 
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instrumentation of the system. For example, runtime monitoring systems 
such as Tracematches [3] and MOP [6] use aspect-oriented technology to 
“hook” relevant observation points and appropriate event filters in a system. 

It is customary to define safety properties as properties over infinite 
traces, to capture the intuition that they are defined for systems that can 
potentially run forever, such as reactive systems. A point in favor of infinite 
traces is that finite traces can be regarded as special cases of infinite traces, 
namely ones that “stutter” indefinitely in their last state (see, for example, 
Abadi and Lamport [1, 2]). Infinite traces are particularly desirable when one 
specifies safety properties using formalisms that have infinite-trace semantics, 
such as linear temporal logics or corresponding automata. 

While “infinity” is a convenient abstraction that is relatively broadly- 
accepted nowadays in mathematics and in theoretical foundations of com- 
puter science, there is no evidence so far that a system can have an infinite- 
trace behavior (we have not seen any). A disclaimer is in place here: we do 
not advocate finite-traces as a foundation for safety properties; all we try 
to do is to argue that, just because they can be seen as a special case of 
infinite traces, finite traces are not entirely uninteresting. For example, a 
safety property associated to a one-time-access key issued to a client can 
be “activate, then use at most once, then close”. Using regular patterns 
over the alphabet of relevant events © = { activate, use, close}, this safety 
property can be expressed as “activate - (€ + use) - close”; any trace that is 
not a prefix of the language of this regular expression violates the property, 
including any other activation or use of the key after it was closed. While 
these finite-trace safety properties can easily be expressed as infinite-trace 
safety properties, we believe that that would be more artificial than simply 
accepting that in practice we deal with many finite-trace safety properties. 

In this section we discuss various approaches for formalizing safety 
properties and show that they are ultimately directly or indirectly equivalent. 
We categorize them into finite-trace safety properties, infinite-trace safety 
properties, and finite- and infinite-trace safety properties: 


1. Section 3.1 defines safety properties over finite traces as prefix closed 
properties. A subset of finite-trace safety properties, that we call 
persistent, contain only traces that “have a future” within the property, 
that is, finite traces that can be continued into other finite traces that 
are also in the safety property. Persistent safety properties appear to 
be the right finite-trace variant that corresponds faithfully to the more 
conventional infinite-trace safety properties. Even though persistent 
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safety properties form a proper subset of finite-trace safety properties 
and each finite-trace safety property has a largest persistent safety 
property included in it, we show that there is in fact a bijection between 
safety properties and persistent safety properties by showing them 
both to have the cardinal of the continuum c. 


. In Section 3.2, we consider two standard infinite-trace definitions of a 


safety property, one based on the intuition that violating behaviors must 
manifest so after a finite number of events and the other based on the 
intuition of a safety property as a closed set in an appropriate topology 
over infinite-traces. We show them both equivalent to persistent safety 
properties over finite traces, by constructing an explicit bijection (as 
opposed to using cardinality arguments and infer the existence of a 
bijection); consequently, infinite-trace safety properties also have the 
cardinal of the continuum c. Since closed sets of real numbers are 
in a bijective correspondence with the real numbers, we indirectly 
rediscover Alpern and Schneider’s result [4] stating that infinite-trace 
safety properties correspond to closed sets in infinite-trace topology. 


. Section 3.3 considers safety properties defined over both finite and 


infinite traces. We discuss two definitions of such safety properties 
encountered in the literature, and, using cardinality arguments, we 
show their equivalence with safety properties over only finite traces. In 
particular, safety properties over finite and infinite traces also have the 
cardinality of the continuum c. We also show that prefix-closeness is not 
a sufficient condition to characterize (not even bijectively) such safety 
properties, by showing that there are significantly more (2°) prefix- 
closed properties over finite and infinite traces than safety properties. 


Therefore, each of the classes of safety properties is in bijection with the real 
numbers. Since there are so many safety properties, we can also insightfully 
conclude that there is no enumerable mechanism to define all the safety 
properties, because No < c. Therefore, particular logical or syntactic recursive 
formalisms can only define some of the safety properties, but not all of them. 


3.1 


Safety Properties over Finite Traces 


One of the most common intuitions for a safety property is as a prefix-closed 
set of finite traces. This captures best the intuition that once something 
bad happened, there is no way to recover: if w ¢ P then there is no u 
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such that P(wu), which is equivalent to saying that if P(wu) then P(w), 
which is equivalent to saying that P is prefix closed. From a monitoring 
perspective, a prefix closed property can be regarded as one containing all 
the good (complete or partial) behaviors of the observed system: once a 
state is encountered that does not form a good behavior together with the 
previously observed states, then a violation can be reported. 


Definition 1 Let prefixes: 5* — P(X*) be the prefix function returning 
for any finite trace all its prefixes, and let prefixes: P(%*) + P(X*) be its 
corresponding closure operator that takes sets of finite traces and closes them 
under prefixes. 


Note that prefixes :P(*) — P(*) is indeed a closure operator, that is, 
it is extensive (P C prefixes(P)), monotone (P C P’ implies prefixes(P) C 
prefixes(P’)), and idempotent (prefixes(prefixes(P)) = prefixes(P)). 


Definition 2 Let Safety* be the set of finite-trace prefiz-closed properties, 
that is, the set {P € P(X*) | P = prefixes(P)}. In other words, Safety* is 
the set of fixed points of the prefix operator prefixes : P(%*) + P(d*). 


The star superscript in Safety” reflects that its traces are finite; in the 
next section we will define a set Safety” of infinite-trace safety properties. 
Since prefixes(P) € Safety* for any P € P(X*), we can assume from here on 
that prefixes: P(h*) + P(d*) is actually a function P(X*) > Safety*. 


Example 1 Consider the one-time-access key safety property discussed 
above, saying that a client can “activate, then use at most once, and then 
close” the key. If © = { activate, use, close}, then this safety property can be 
expressed as the finite set of finite words 


{e, activate, activate close, activate use, activate use close} 


No other behavior is allowed. Now suppose that the safety policy is extended 
to allow multiple uses of the key once activated, but still no further events 
once it is closed. The extended safety property has now infinitely many 
finite-traces: 


{e} U {activate} - {use” | n € N}- {e, close}. 


Note that this property is indeed prefix-closed. A monitor in charge of online 
checking this safety property would report a violation if the first event is 
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not activate, or if it encounters any second activate event, or if it encounters 
any event after a close event is observed, including another close event. 

It is interesting to note that this finite-trace safety property encompasses 
both finite and infinite aspects. For example, it does not preclude behaviors in 
which one sees an activate event and then an arbitrary number of use events; 
use events can persist indefinitely after an activate event without violating 
the property. On the other hand, once a close event is encountered, no other 
event can be further seen. We will shortly see that the safety property above 
properly includes the persistent safety property {e}U { activate use” | n € N}, 
which corresponds to the infinite-trace safety property {activate use’ }. 


While prefix closeness seems to be the right requirement for a safety 
property, one can argue that it is not sufficient. For example, in the context 
of reactive systems that supposedly run forever, one may think of a safety 
property as one containing safe finite traces, that is, ones for which the 
reactive system can always find a way to continue its execution safely. The 
definition of safety properties above includes, among other safety properties, 
the empty set of traces as well as all prefix-closed finite sets of finite traces; 
any reactive system will eventually violate such safety properties, so one can 
say that the definition of safety property above is too generous. 

We next define persistent safety properties as ones that always allow 
a future; intuitively, an observed reactive system that is in a safe state 
can always (if persistent enough) find a way to continue its execution to 
a next safe state. This notion is reminiscent of “feasibility”, a semantic 
characterization of fairness in [5], and of “machine closeness” [1, 13], also 
used in the context of fairness. 


Definition 3 Let PersistentSafety* be the set of finite-trace persistent safety 
properties, that is, safety properties P € Safety* such that if P(w) for some 
w € &* then there is some a € & such that P(wa). 


If a persistent safety property is non-empty, then note that it must 
contain an infinite number of words. The persistency aspect of a finite-trace 
safety property can be regarded, in some sense, as a liveness argument. 
Indeed, assuming that it is a “good thing” for a trace to be indefinitely 
continued, then a persistent safety property is one in which the “good 
thing” always eventually happens. If one takes the liberty to regard “stuck” 
computations as unfair, then the persistency aspect above can also be 
regarded as a fairness argument. 
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Another way to think of persistent safety properties is as a means to refer 
to infinite behaviors by means of finite traces. This view is, in some sense, 
dual to the more common approach to regard finite behaviors as infinite 
behaviors that stutter infinitely in a “last” state (see, for example, Abadi 
and Lamport [1, 2] for a formalization of such last-state infinite stuttering). 

Note that if % is a degenerate set of events containing only one element, 
that is, if |X| = 1, then |Safety*| = No and |PersistentSafety*| = 2; indeed, if 
» = {a} then Safety* contains precisely the finite properties aS" = {a’ | 0 < 
i <n} for each n € N plus the infinite property {a” | n € N}, so a total of 
No + 1 = No properties, while PersistentSafety* contains only two properties, 
namely ( and {a” | n € N}. The case when there is only one event or state in 
& is neither interesting nor practical. Therefore, from here on in this paper 
we take the liberty to assume that |X| > 2. Since in practice © contains 
states or events generated by a computer, for simplicity in stating some of the 
subsequent results, we also take the liberty to assume that |©| < No; therefore, 
x can be any finite or recursively enumerable set, including N, Nou, Q, etc., 
but cannot be R or any set “larger” than R. With these assumptions, it 
follows that |%*| = No (finite words are recursively enumerable) and |X”| = c 
(infinite streams have the cardinality of the continuum). 


Proposition 1 Safety* and PersistentSafety* are closed under union; Safety* 
is also closed under intersection. 


Proof: The union and the intersection of prefix-closed properties is also 
prefix-closed. Also, the union of persistent prefix-closed properties is also 
persistent. 


The intersection of persistent safety properties may not be persistent: 


Example 2 Let © be the set {0,1}. Let P = {1” | m € N} and P’ = 
{e} U {10™ | m € N} be two persistent safety properties, where «€ is the 
empty word (the word containing no letters). Then PM P’ is the finite 
safety property {e,1}, which is not persistent. If one thinks that this 
happened because PM P’ does not contain any proper (i.e., non-empty) 
persistent property, then one can take instead the persistent safety properties 
P={0"|n Ee N}-{1" | me N} and P’ = {0" | n € N}-({e}U{10™ | m € N}, 
whose intersection is the safety property {0" |n € N}U{0"1 | n € N}. This 
safety property is not persistent because its words ending in 1 cannot persist, 
but it contains the proper persistent safety property {0” | n € N}. 
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Therefore, we can associate to any safety property in Safety” a largest 
persistent safety property in PersistentSafety*, by simply taking the union 
of all persistent safety properties that are included in the original safety 
property (the empty property is one of them, the smallest): 


Definition 4 For a safety property P € Safety*, let P° © PersistentSafety* 
be the largest persistent safety property with P° C P. 


The following example shows that one may need to eliminate infinitely 
many words from a safety property in order to obtain a persistent safety 
property: 


Example 3 Let © = {0,1} and let P be the safety property {0" | n € 
N}U {0"1 | n © N}. Then P®° can contain no word ending with a 1 and can 
contain all the words of 0’s. Therefore, P° = {0” | n € N}. 


Finite safety properties obviously cannot contain any non-empty persis- 
tent safety property, that is, P° = @ if P is finite. But what if P is infinite? 
Is it always the case that it contains a non-empty persistent safety property? 
Interestingly, it turns out that this is true if and only if » is finite: 


Proposition 2 If % is finite and P is a safety property containing infinitely 
many words, then P° #(. 


Proof: For each letter a € %, let us define the derivative of P wrt a, 
written 6(P), as the language {w € 4* | aw € P}. Since 


P ={e}u [J {a} -64(P) 


aed 


since © is finite, and since P is infinite, it follows that there is some a; € & 
such that 6q,(P) is infinite; note that a; € P since P is prefix closed. 
Similarly, since 5,,(P) is infinite, there is some az € Y such that da (da, (P)) 
is infinite and a,a2 € P. Iterating this reasoning, we can find some a, € 
for each n € N, such that ajag...an € P and daq,, (+++ (az (0a, (P))) +++) is 
infinite, that is, the set {w € b* | ajag...anw € P} is infinite. It is now 
easy to see that the set {a,a2...an | n € N} C P is persistent. Therefore, 
PAG, 

The following example shows that % must indeed be finite in order for 
the result above to hold: 
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Example 4 Consider some infinite set of events or states ©. Then we can 
label distinct elements in © with distinct labels in NU {oo}. We only need 
these elements from ©; therefore, without loss of generality, we can assume 
that & = NU {oo}. Let P be the safety property 


{e} Uf{oon(n—1)...(m4+1)m|0<m<n+]}, 


where € is the empty word (the word containing no letters) and n...(n + 1) 
is also the empty word for any n € N. Then P°® is the empty property. 
Indeed, note that any persistent safety property P’ included in P cannot 
have traces ending in 0, because those cannot be continued into other traces 
in P; since P’ cannot contain traces ending in 0, it cannot contain traces 
ending in 1 either, because such traces can only be continued with a 0 letter 
into traces in P, but those traces have already been decided that cannot be 
part of P’; inductively, one can show that P’ can contain no words ending in 
letters that are natural numbers in N. Since the only trace in P ending in co 
is co itself and since co can only be continued with a natural number letter 
into a trace in P but such trace cannot belong to P’, we deduce that P’ can 
contain no word with letters in ©. In particular, P° must be empty. 


Even though we know that the largest persistent safety property P° 
included into a safety property P always exists because PersistentSafety * 
is closed under union, we would like to have a more constructive way to 
obtain it. A first and obvious thing to do is to eliminate from P all the 
“stuck” computations, that is, those which cannot be added any new state 
to obtain a trace that is also in P. This removal step does not destroy the 
prefix-closeness of P, but it may reveal new computations which are stuck. 
By iteratively eliminating all the computations that get stuck in a finite 
number of steps, one would expect to obtain a persistent safety property, 
namely precisely P°. It turns out that this is indeed true only if » is finite. 
If that is the case, then the following can also be used as an alternative 
definition of P°: 


Proposition 3 Given safety property P © Safety*, then let P~ be the 
property {w€ P|(sa€=¥)wa € P}. Also, let {P; | i € N} be properties 
defined as Fy’ = P and Pay: Pe foralls.> 0... Then. P° = Ig he 
whenever & is finite. . 


Proof: It is easy to see that if P is prefix-closed then P~ C P is also 
prefix-closed, so P~ is also a property in Safety”. Therefore, the properties 
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P,; form a sequence P = Pp D Pi D Pp D--- of increasingly smaller safety 
properties. 

Let us first prove that (),., P; is a persistent safety property. Assume 
by contradiction that for some w € ();s9 Pn there is no a € © such that 
wa € Gheees In other words, we can find for each a € © some ig > 0 
such that wa ¢ P;,. Since D is finite, we can let i be the largest among 
the natural numbers i, € N for alla € XU. Since P; C P,, for all a € &, 
it should be clear that there is no a € © such that wa € P;, which means 
that w ¢ P41. This contradicts the fact that w € (),s) Pi. Therefore, 
Nixo Pi € PersistentSafety *. 7 

~ Let us now prove that (+o Fi is the largest persistent safety property 
included in P. Let P’ be any persistent safety property included in P. We 
show by induction on i that P’ C P; for all i € N. The base case, P’ C Po, 
is obvious. Suppose that P’ C P; for some i € N and let w € P’. Since P’ 
is persistent, there is some a € © such that wa € P’ C P;, which means 
that w € Pj41. Since w was chosen arbitrarily, it follows that P’ C Pj41. 
Therefore, P’ C (jo F- 

We next show that the finiteness of 5 was a necessary requirement in 
order for the result above to hold. In other words, we show that if © is 
allowed to be infinite then we can find a safety property P € Safety* over © 
such that P° € PersistentSafety* and (),., P; € Safety are distinct. Since 
we showed in the proof of Proposition 3 that any persistent safety property 
P’ is included in ()j;39 Pi, it follows that P° C ()j39 Pi. Since P® is the 
largest persistent safety property included in P, one can easily show that 
P° = (()js9 Pi)°. Therefore, it suffices to find a safety property P such that 
see is not persistent, which is what we do in the next example: 


Example 5 Consider the safety property P over infinite © = NU {co} 
discussed in Example 4, namely {e} U {oon(n—1)...(m+1)m|0<m< 
n+ 1}. Then one can easily show by induction on 7 € N that the properties 
P, defined in Proposition 3 are the sets {e} U{oon(n—1)...(m4+1)m]li< 
m <n-+1}; in other words, each P; excludes from P all the words whose 
last letters are smaller than 7 when regarded as natural numbers. Then the 
intersection (},.9 P; contains no trace ending in a natural number; the only 
possibility left is then (;9 P; = {e, co}, which is different from P° = 0) (see 
Example 4). - 

One may argue that P° 4 ();s, P; above happened precisely because 
P° was empty. One can instead pick the safety property Q = {0” | n € 
N}-P. Then one can show following the same idea as in Example 4 that 
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Q° = {0" | n € N}. Further, one can show that Q; = {0" | n € N}- Pj, so 
Miso Qi = {0" | n € N} U {0"00 | n € N}, which is different from Q°. 


Persistency is reminiscent of “feasibility” introduced by Apt et al. [5] in 
the context of fairness, and of “machine closeness” introduced by Abadi and 
Lamport [1, 2] (see also Schneider [13]) in the context of refinement. Let us 
use the terminology “machine closeness”: a property L (typically a liveness 
or a fairness property) is machine closed for a property M (typically given 
as the language of some state machine) iff Z does not prohibit any of the 
observable runtime behaviors of M, that is, iff prefixes(/) = prefixes( 7M L); 
for example, if MW is the total property (i.e., every event is possible at 
any moment, i.e., M = %*) and L is the property stating that “always 
eventually event a”, then any prefix of M can be continued to obtain a 
property satisfying L. Persistency is related to machine closeness in that a 
safety property P is persistent if and only if P° is machine closed for P. In 
other words, there is nothing P can do in a finite amount of time that P° 
cannot do. However, there is a caveat here: since liveness and fairness are 
inherently infinite-trace notions, machine closeness (or feasibility) have been 
introduced in the context of infinite-traces. On the other hand, persistency 
makes sense only in the context of finite traces. 

It is clear that PersistentSafety* is properly included in Safety*. Yet, 
we next show that, surprisingly, there is a bijective correspondence between 
Safety* and PersistentSafety*, both having the cardinal of the continuum: 


Theorem 1 |PersistentSafety*| = |Safety*| = c. 


Proof: Since D* is recursively enumerable and since 28° = c, we can 
readily infer that |PersistentSafety*| < |Safety*| < |P(X*)| =c. 

Let us now define an injective function y from the open interval of 
real numbers (0,1) to PersistentSafety*. Since || > 2, let us distinguish 
two different elements in © and let us label them 0 and 1. For a real 

€ (0,1), let y(r) be the set {@ | a € {0,1}* and 0.a < r}, where 0.a 
is the (rational) number in (0,1) whose decimals in binary representation 
are a, and where @ is the word in »* corresponding to a. Note that the 
set y(r) € P(=*) is prefix-closed for any r € (0,1), and that if w € y(r) 
then also w0 € y(r) (the latter holds since, by real numbers conventions, 
0.2 = 0.a0), so y(r) € PersistentSafety*. Since the set of rationals with 
finite number of decimals in binary representation is dense in R (i.e., it 
intersects any open interval in R) and in particular in the interval (0, 1), it 
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follows that the function y : (0,1) — PersistentSafety™~ is injective: indeed, 
ifr, A rg € (0,1), say m1 < re, then there is some a € {0,1}* such 
that ry < 0.a < rg, so y(ri) # y(r2). Since the interval (0,1) has the 
cardinal of the continuum c, the existence of the injective function y implies 
that c < |PersistentSafety*|. By the Cantor-Bernstein-Schroeder theorem it 
follows that |PersistentSafety*| = |Safety*| = c. 

With regards to finite-traces, persistent safety properties appear to 
be more natural in the context of reactive systems than just prefix-closed 
properties. Also, persistent safety properties play a technical bridge role in 
the next section to show that the infinite-trace safety properties also have 
the cardinal c. 


3.2 Safety Properties over Infinite Traces 


The finite-trace safety properties defined above, persistent or not, rely on the 
intuition of a correct prefix: a safety property is identified with the set of all 
its finite prefixes. In the case of a persistent safety property, each “informal” 
infinite acceptable behavior is captured by its infinite set of finite prefixes. 
Even though persistent safety properties appear to capture well, in a finite- 
trace setting, the intuition of safety in the context of (infinite-trace) reactive 
systems, one could argue that it does not say anything about unacceptable 
infinite traces. Indeed, one may think that persistent safety properties do not 
capture the intuition that if an infinite trace is unacceptable then there must 
be some finite prefix of it which is already unacceptable. In this section we 
show that there is in fact a bijection between safety properties over infinite 
traces and persistent safety properties over finite traces, as we defined them 
in the previous section. 
We start by extending the prefixes function to infinite traces: 


Definition 5 Let prefixes: ” — P(X*) be the function returning for any 
infinite trace u all its finite prefixes prefixes(u), and let prefixes: P(X”) > 
P(d*) be its corresponding extension to sets of infinite traces. 


Note that prefixes(.S) € PersistentSafety* for any S € P(X”), so prefixes 
is in fact a function P(X”) — PersistentSafety *. 

The definition of safety properties over infinite traces below appears 
to be the most used definition of a safety property in the literature; to our 
knowledge, it was formally introduced by Alpern and Schneider [4], but they 
credit the insights of their definition to Lamport [9]. 
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Definition 6 Let Safety” be the set of infinite-trace properties Q € P(X”) 
s.t.: ifuZQ then there is a finite trace w € prefixes(u) s.t. wu ¢€ Q for any 
ve bY, 


In other words, if an infinite behavior violates the safety property then 
there is some finite-trace “violation threshold”; once the violation threshold 
is reached, there is no chance to recover. 

The following proposition can serve as an alternative and more compact 
definition of Safety”: 


Proposition 4 Safety” = {Q © P(X”) |u € Q iff prefixes(u) C prefixes(Q)}. 


Proof: Since u € Q implies prefixes(w) C prefixes(Q), the only thing left 
to show is that Q € Safety” iff “prefixes(u) C prefixes(Q) implies u € Q”; 
the latter is equivalent to “uw ¢ Q implies prefixes(u) Z prefixes(Q)”, which 
is further equivalent to “u ¢ Q implies there is some w € prefixes(u) s.t. 
w ¢ prefixes(Q)”, which is indeed equivalent to Q € Safety”. 

Another common intuition for safety properties over infinite traces is 
as closed sets in the topology corresponding to &”. Alpern and Schneider 
captured formally this intuition for the first time in [4]; then it was used as 
a convenient definition of safety by Abadi and Lamport [1, 2] among others: 


Definition 7 An infinite sequence u™), u), ..., of infinite traces in DY” 


converges to u € ©”, or u is a limit of u), ul), ...,, written u = lim, u, iff 
for allm > 0 there is ann > 0 such that uy ec yo = U1U2Q...Um for all 
i>n. IfQ€ P(X") then Q, the closure of Q, is the set flimju | u™ € 
Q for alli € N}. 


It can be easily shown that the overline closure above is indeed a closure 
operator on &”, that is, it is extensive (Q C Q), monotone (Q C @ implies 


Q C Q’), and idempotent (Q = Q). 

Definition 8 Let Safety’, be the set of properties {Q € P(X”) | Q=Q}. 
As expected, the two infinite-trace safety property definitions are equiv- 

alent; we have not found any formal proof in the literature, so for the sake 


of completeness we give a simple proof here: 


Proposition 5 Safety;7,, = Safety”. 
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Proof: All we need to prove is that for any Q € P(}”) and any u € &”, 
prefixes(u) C prefixes(Q) iff u = lim; u for some infinite sequence of infinite 
traces u), ul2). If prefixes(u) C prefixes(Q) then one can find for each i > 0 


@) @) : u®, so for each m > 0 


one can pick n = m such that uju2...Um = ul? @) one u for all i > n, so 
u = lim; u™. Conversely, if u = lim; u for some infinite sequence of infinite 
traces u), ul), ... in NY, then for any m > 0 there is some n > 0 such 
that ujug...Um = uo yy is Ae that is, for any prefix of u there is some 
u’ € Q having the same prefix, that is, prefixes(w) C prefixes(Q). 

The next result establishes the relationship between infinite-trace safety 
properties and finite-trace persistent safety properties, by proposing a con- 
crete bijective mapping relating the two (as opposed to using cardinality 
arguments to indirectly show only the existence of such a mapping). There- 
fore, there is also a bijective correspondence between safety properties over 


infinite traces and the real numbers: 


some u € XS” such that UjUQ...Uj, = U 


Theorem 2 |Safety”| = |PersistentSafety”| = c. 


Proof: We show that there is a bijective function between the two sets 
of safety properties. Recall that prefixes(S) € PersistentSafety* for any S € 
P(=”), that is, that prefixes is a function P(”) — PersistentSafety*. Let 
prefixes : Safety” —> PersistentSafety* be the restriction of this prefix function 
to Safety”. Let us also define a function w : PersistentSafety* — Safety” as 
follows: w(P) = {u € %* | prefixes(w) C P}. This function is well-defined: if 
u ¢ w(P) then by the definition of w(P) there is some w € prefixes(u) such 
that w ¢ P; since w € prefixes(wv) for any v € ©”, it follows that wu ¢ w(P) 
for any v € &”. 

We next show that prefixes and w are inverse to each other. Let us first 
show that prefixes(w(P)) = P for any P € PersistentSafety*. The inclusion 
prefixes(w(P)) C P follows by the definition of w(P): prefixes(wu) C P for any 
u € w(P). The inclusion P C prefixes(w(P)) follows from the fact that P is a 
persistent safety property: for any w € P one can iteratively build an infinite 
sequence U1, U2, ..., such that wv1, wuive, ... € P, so wvjiv2... € w(P). Let us 
now show that w(prefixes(Q)) = Q for any Q € Safety”. The inclusion Q C 
w(prefixes(Q)) is immediate. For the other inclusion, let u € w(prefixes(Q)), 
that is, prefixes(u) C prefixes(Q). Suppose by contradiction that u ¢ Q. 
Then there is some w € prefixes(u) such that wu ¢ Q for any v € &”. Since 
w € prefixes(w) and prefixes(w) C prefixes(Q), it follows that w € prefixes(Q), 
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that is, that there is some u’ € Q such that u’ = wv for some v € S”. This 
contradicts the fact that wv ¢ Q for any v € &”. Consequently, u € Q. 
The second part follows by Theorem 1. 


3.3 Safety Properties over Finite and Infinite Traces 


It is also common to define safety properties as properties over both finite 
and infinite traces, the intuition for the finite traces being that of unfinished 
computations. For example, Lamport [10] extends the notion of safety in 
Definition 6 to properties over both finite and infinite traces, while Schneider 
et al [14, 7] give an alternative definition of safety over finite and infinite 
traces. We present both approaches shortly and then show their equivalence 
and their bijective correspondence with real numbers. Before that, we argue 
that the mix of finite and infinite traces is less trivial than it may appear, 
by showing that there are significantly more prefix closed properties than in 
the case when only finite traces were considered. 


Definition 9 Let PrefixClosed*” be the set of prefix-closed sets of finite and 
infinite traces: for Q C U* UX”, Q € PrefixClosed*™ iff prefixes(Q) C Q. 
Also, let PersistentPrefixClosed*” be the set of persistent prefiz-closed sets 
of finite and infinite traces: for Q € PrefixClosed*”, it is the case that 
Q € PersistentPrefixClosed*” <=> if Q(w) for some w € &* then that there 
is some a € & such that Q(wa). 


The next result says that there is a bijective correspondence between 
prefix-closed and persistent prefix-closed properties also in the case of finite 
and infinite traces, but that there are exponentially more such properties 
than in the case of just finite traces: 


Proposition 6 |PersistentPrefixClosed*”| = |PrefixClosed**”| = 2°. 


Proof: We show 2° < |PersistentPrefixClosed *”| < |PrefixClosed**| < 2°, 
where the middle inequality is immediate. For 2° < |PersistentPrefixClosed*’”|, 
let us define y:P((0,1)) — PersistentPrefixClosed*” as 


o(R) = |) {a} U prefixes(@) 
0.aER 


where we assume for any real number in the interval (0,1) its decimal binary 
representation 0.a@ with a € {0,1} (if the number is rational then a may 
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contain infinitely many ending 0’s), and @ is the infinite trace in ©“ replacing 
each 0 and 1 in a by 0 and 1, respectively, where 0 and 1 are two arbitrary 
but fixed distinct elements in © (recall that |X| > 2). Note that y(R) is 
well-defined: it is clearly prefix-closed and it is also persistent because its 
finite traces are exactly prefixes of infinite traces, so they admit continuations 
in y(R). It is easy to see that y is injective. Since |(0,1)| = c, we conclude 
that 2° < |PersistentPrefixClosed*]. 

To show |PrefixClosed *”| < 2°, note that any property in PrefixClosed*” 
is a union of a subset in 4* and a subset in )”, so |PrefixClosed**| < 
gi=*1.9|="1, Since |Z*| = No, |E”| = c, 28 = c, and c- 2° = 2° (by absorption 
of transfinite cardinals), we get that |PrefixClosed*”| < 2°. 

The fact that properties in PersistentPrefixClosed*” also contain infinite 
traces was crucial in showing the injectivity of y in the proof above. A 
similar construction for the finite trace setting does not work. Indeed, if 
one tries to define a function y:P((0,1)) — PersistentSafety* as y(R) = 
Uo.cer Prefixes(@), then one can show that it is well-defined but cannot show 
that it is injective: e.g., y((0,0.5)) = y((0, 0.5]). 

Since safety properties over finite and infinite traces are governed by 
the same intuitions as safety properties over only finite or over only infinite 
traces, the result above tells us that prefix closeness is not a sufficient 
condition to properly capture the safety properties. Schneider [14] proposes 
an additional condition in the context of his EM (execution monitoring) 
framework, namely that if an infinite trace is not in the property, then there 
is a finite prefix of it which is not in the property either. It is easy to see 
that this additional condition is equivalent to saying that an infinite trace 
is in the property whenever all its finite prefixes are in the property, which 
allows us to compactly define safety properties over finite and infinite traces 
in the EM style as follows: 


Definition 10 Safetyzy = {QC X*ULXY | we Q iff prefixes(u) C Q}. 


Note that Safetyfi; C PrefixClosed*”. We will shortly show that 
Safetyery is in fact exponentially smaller than PrefixClosed*”, by showing 
that |Safetyp)| = c. 

The traditional definition of a safety property in the context of both 
finite and infinite traces is perhaps the one proposed by Lamport in [10], 
which relaxes the one in Definition 6 by allowing wu to range over both finite 


and infinite traces: 


Definition 11 Let Safety*” be the set of finite- and infinite-trace properties 
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{QC U*ULY | u¢Q = (Au € prefixes(u)) (Vu € X* UX”) wu ¢ Q} 


Schneider informally stated in [14] that the two definitions of safety 
above are equivalent. It is not hard to show it formally: 


Proposition 7 Safetyzj = Safety*”. 


Proof: First note that Safety*” C PrefixClosed*”: if wu € Q € Safety*” 
and w ¢ Q then there is some w’ € prefixes(w), say w = w’w”, such that 
w’'v ¢ Q for any v, in particular w’w"u ¢ Q, which contradicts wu € Q. 

Safety*” C Safetyfiy: let Q € Safety*” and u € N*UL s.t. prefixes(u) C 
Q; ifu ¢ Q then there is some w € prefixes(u) s.t. wu ¢ Q for any v, in partic- 
ular for v the 2 empty word, that is, w ¢ Q, which contradicts prefixes(u) C Q. 

Safetyfuy C Safety*”: let u ¢ Q € Safetye,7’; then prefixes(u) Z Q, that 
is, there is some w € prefixes(w) s.t. w ¢ Q; since Q is prefix-closed, it 
follows that wv ¢ Q for any v € X* UX”. 

We next show that there is a bijective correspondence between the 
safety properties over finite or infinite traces above and the finite trace safety 
properties in Section 3.1: 


Theorem 3 |Safety*’| = |Safetyzy| = |Safety*| = c. 
Proof: — Safety* C Safetyen since the properties in Safety-,, are prefix- 
closed, so |Safety*| < |Safety¢jy 

Since the functions prefixes : P(E") — P(d*) and prefixes: P(X”) > 
P(=*) have actual co-domains Safety* and PersistentSafety”, respectively, 
they can be organized as a function prefixes: Safetyriy — Safety*. Let us 
show that this function is injective. Let us assume "Q #QeE Safetyfyy 
say u € Q and u ¢ Q’, s.t. prefixes(Q) = prefixes(Q’). Since u € Q € 
Safety-,, it follows that prefixes(w) C prefixes(Q) C Q, which implies that 
prefixes(u) C prefixes(Q’) C Q’; since Q! € Safetyem it follows that u € Q’, 
contradiction. Therefore, prefixes: Safetyeiy — Safety* is injective, which 
proves that Safetyp;, < Safety*. 

The rest follows by Proposition 7 and Theorem 1. 


3.4 “Always Past” Characterization of Safety Properties 


Another common way to specify safety properties is by giving an arbitrary 
property on finite traces, not necessarily prefix closed, and then to require 
that any acceptable behavior must have all its finite prefixes in the given 
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property. A particularly frequent case is when one specifies the property 
of the finite-prefixes using the past-time fragment of linear temporal logics 
(LTL). For example, Manna and Pnueli [11] call the resulting “always (past 
LTL)” properties safety formulae; many other authors, including ourselves, 
adopted the terminology “safety formula” from Manna and Pnueli, although 
some qualify it as “LTL safety formula”. An example of an LTL safety 
formula is “always (b implies eventually in the past a)”, written using LTL 
notation as “L(b > ea)”; here the past time formula “b — ea” compactly 
specifies all the finite-traces 


{wsu’s’ | w,w’ € &*, s,s’ © N, a(s) and 6(s’) hold} U 
{ws | w € &*, s © ©, b(s) does not hold}. 


In the remainder of this section we assume that the past time prefix properties 
are given as ordinary sets of finite-traces (so we make abstraction of how 
these properties are expressed) and show not only that the resulting “always 
past” properties are safety properties, but also that any safety properties can 
be expressed as an “always past” property. This holds for all the variants 
of safety properties (i.e., over finite traces, over infinite traces, or over both 
finite and infinite traces). 


Definition 12 Let P C &* be any property over finite traces. Then we 
define the “always past” property UP as follows: 


(finite traces) {w € d* | prefixes(w) C P}; and 
(infinite traces) {u € XU” | prefixes(u) C P}; and 
(finite and infinite traces) {u € &* US” | prefixes(u) C P}. 


Let Safety, Safety$ and Safety~” be the corresponding sets of properties. 


6 oe 


Intuitively, one can regard the square as a closure operator. Tech- 
nically, it is not precisely a closure operator because it does not operate 
on the same set: it takes finite-trace properties to any of the three types 
of properties considered. Since prefixes takes properties back to finite-trace 
properties, we can show the following result saying that the square is a 
“closure operator via prefixes”, and that safety properties are precisely the 


sets of words which are closed this way: 


Proposition 8 The following hold for all three types of safety properties: 
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e O(prefixes(P)) =OP for any P C &*; 


e Q is a safety property iff O(prefixes(Q)) = Q. 


Proof: Left as an exercise to the reader. 
We next show that the “always past” properties are all safety properties 
and, moreover, that any safety property can be expressed as an “always past” 


property: 
Theorem 4 The following hold: 


e Safetys = Safety”, 


e Safety4 = Safety”, and 


e Safety” = Safety*”. 


Therefore, each of the “always past” safety properties have the cardinal c. 


Proof: We prove each of the equalities by double inclusion. 


Safety C Safety*. It is true because any property LJP in Safety? is prefix- 
closed. 


Safety* C Safety®. If P © Safety* then we claim that P = OP, so P € 
Safety4. Indeed, since P is prefix-closed, prefixes(w) C P for any 
w € P, so w € OP; also, since w € prefixes(w), it follows that for any 
we€UOP,we P. 


JE 


SafetyS C Safety”. Let OP be an “always past” property in SafetyS, and 
let u be an infinite trace in &” such that u ¢ OP. Then it follows 
that prefixes(u) Z P, that is, there is some w € prefixes(u) such that 
w ¢ P. Since w € prefixes(wv) for any v € ©“, it means that there 
is no v € UP such that prefixes(wv) C P, that is, there is no v € ©” 
such that wv € DIP. Therefore, LIP € Safety”. 


Safety” C Safety4. If Q © Safety” then we claim that Q = Lprefixes(Q). 
The inclusion Q C Lprefixes(Q) is clear, because u € Q implies 
prefixes(u) C prefixes(Q). For the other inclusion, remark that if 
prefixes(u) C prefixes(Q) for some u € %&”, then wu must be in Q: 
if u ¢ Q then by the definition of Q © Safety”, there is some 
w € prefixes(w) which cannot be completed into an infinite trace in Q, 
which contradicts prefixes(u) C prefixes(Q). 
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* 


Safety” C Safety*”. By Proposition 7, it suffices to show that Safety4’” C 
Safetyery . Let OP be an “always past” property in Safety“, and let 
u € )*UX” such that prefixes(w) C prefixes(P). Since prefixes(OP) C 
P, it follows that u € UIP; therefore, UP € Safetyfy- 


* 


Safety*” C Safety”. It is straightforward to see that Q € Safetyfiy implies 
Q = Uprefixes(Q). 


The cardinality part follows by Theorems 1, 2, and 3. 


Proposition 8 and Theorem 4 give yet another characterization for safety 
properties over any of the three combinations of traces, namely one in the 
style of the equivalent formulation of safety over infinite traces in Proposition 
4: Q is a safety property iff it contains precisely the words whose prefixes 
are in prefixes(Q). 


4 On Monitoring Safety Properties 


In this section we give yet another characterization of safety properties, 
namely as monitorable properties. Specifically, we formally define a monitor 
as a (possibly infinite) state machine without final states but with a partial 
transition function, and then we show that safety properties are precisely 
the properties that can be monitored with such monitors. We then elaborate 
on the problem of defining the complexity of monitoring a safety property, 
discussing some pitfalls and guiding principles, and show that monitoring a 
safety property can be an arbitrarily hard problem. Finally, we give a more 
compact and mathematical equivalent definition of a monitor, which may be 
useful in further foundational efforts in this area. 


4.1 Specifying Safety Properties as Monitors 


Safety properties are difficult to work with as flat sets of finite or infinite 
words, not only because they can contain infinitely many words, but also 
because such a flat representation is inconvenient for further analysis. It is 
important therefore to specify safety properties using formalisms that are 
easier to represent and reason about. Formalisms known to be useful for 
specifying safety properties include regular expressions and temporal logics, 
which can be efficiently translated into finite-state machines which can then 
be used as monitors. In this section we formalize the intuitive notion of a 
monitor as a special state machine and give yet another characterization 
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of safety properties, namely as monitorable properties. Since monitorable 
properties are completely defined by their monitors, it follows that all safety 
properties can be specified by their corresponding monitors. 

Recall that we work under the assumption that © is a set of events or 
program states such that ||] < No. 


Definition 13 A %-monitor, or just a monitor (when ¥ is understood), is 
a triple M = (S,50,M:S x & — S), where S is a set of states, 59 € S is 
the initial state, and M is a deterministic partial transition function. 


Therefore, a monitor as defined above is nothing but a deterministic 
state machine without final states. Moreover, the set of states is allowed to 
be infinite, and the transition function has no complexity requirements (it 
can even be undecidable). We could have defined monitors to be standard 
state machines, but the subsequent technical developments would have been 
slightly more involved. The intuition for a monitor is the expected one: the 
monitor is driven by events generated by the observed program (the letters 
in ©)—each newly received event drives the monitor from its current state to 
some other state, as indicated by the transition function M; if the monitor 
ever gets stuck, that is, if the transition function M is undefined on the 
current state and the current event, then the monitored property is declared 
violated at that point by the monitor. 

For any partial function M:S x = — S, we obey the following com- 
mon notational convention. If s € S and w = wywe...we € X*, we 
write “M(s,w) |” whenever M(s,w) is defined, that is, whenever M(s, w1) 
and M(M(s,w1),we) and... and M(...(M(s, w1), w2)..., we) are all defined, 
which is nothing but only saying that M(...(1/(s,w1), wa)..., wz) is defined. 
If we write M(s,w) = s’ for some s’ € S, then, as expected, we mean that 
M(...(M(s,w1), w2)..., Wx) is defined and equal to s’. 

A monitor specifies a finite-trace property, an infinite-trace property, as 
well as a finite- and infinite-trace property: 


Definition 14 Given a monitor M = (S,50,M:S xX — S), we define the 
following properties: 


e £*(M) = {w € &* | M(s0, w) L}, 
e LY(M) = {ue &” | M(s0,w) | for all w € prefixes(u)}, and 
ee (MM) = 0" (ADU LY OM): 
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We call £L*(M) the finite-trace property specified by M, call LY(M) the 
infinite-trace property specified by M, and call L*”(M) the finite- and 
infinite-trace property specified by M. Also, we let 


Sy ={seES | w € d*) M(so,w) = s} 
denote the set of reachable states of M. 


A monitorable property is a property which can be specified by a monitor. 
We next capture this intuitive notion formally: 


Definition 15 For a property P C ©* UX”, we let Monitors(P) be the set 
of monitors {M | L**(M) = P}. If Monitors(P) 4 0 then P is called 
monitorable and the elements of Monitors(P) are called monitors of P. We 
define the following classes of properties: 


e Monitorable* = {P C &* | P monitorable}, 
e Monitorable* = {P C &” | P monitorable}, and 


e Monitorable** = {P C &* UX” | P monitorable}. 
The notion of persistence can also be adapted to monitors: 


Definition 16 A monitor M = (S,s9,M:S x % — S) is persistent iff for 
any reachable state s € Sy, there is ana € © such that M(s,a) |. Let 


e PersistentMonitorable* = {L*(M) | M persistent} 


be the set of finite-trace properties monitorable by persistent monitors. 


Our next goal is to show that each monitor admits a largest persistent 
“submonitor”. To formalize it, we lift the conventional partial order relation 
on partial functions to monitors: 


Definition 17 If M, = (S,50,M:S x X= S) and Mz = (S, 50, M2: 5S x 
“ — S) are two monitors sharing the same states and initial state, then let 
M,C Mg, read M, asubmonitor of Mo, iff for anys € S and anya e ®, 
if Mi(s,a) is defined then Mo(s,a) is also defined and M2(s,a) = Mi(s,a). 


The above can be easily generalized to allow My, to only have a subset 
of the states of M2, but we found that generalization unnecessary so far. 

The above partial-order on monitors allows us to use conventional 
mathematics to obtain the largest persistent sub-monitor of a monitor: 
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Proposition 9 ({K | K C M andK persistent},C) is a complete (join) 
semilattice for any monitor M. 


Proof: If {K; = (S,s0,Kij:S x } — S) € M}ie; is a set of persistent 
monitors, then their supremum (or join) is the monitor K = (S,s509,k:S x 
= — S) where K(s,a) = 8’ iff there is some 7 € I such that K;(s,a) = s’. It 
is easy to see that K is a well-defined monitor and that it is persistent. 

Since complete semilattices have maximum elements, the following 
definition is fully justified: 


Definition 18 For any monitor M = (S,s0,M:S x 4 — S), we let M° = 
(S, 50, M°:S x 4 — S) be the C-mazimal element of the complete lattice 


({K | KOM andK persistent}, C). 


We next show that, as expected, there is a tight relationship between 
persistent safety properties (Definition 3) and persistent canonical monitors. 


Proposition 10 Let M = (S,s9,M:S x — S). Then the following hold: 
e £°(M) = Le(M?), 
e L*(M°) = L*(M)°, and 
e M persistent iff L*(M) persistent. 


Proof: The first property can be shown by the following sequence of 
equivalences: u € L°(M) iff M(so, w) | for all w € prefixes(w), iff there is 
some persistent monitor K EC M such as K (so, w) | for all w € prefixes(w), 
iff M°(so, w) J for all w € prefixes(u), iff ue LY(M°). 

The second property can be shown as follows: w € £L*(M°) iff M°(so, w) J, 
iff there is some u € LY(M°) such that w € prefixes(u) (because M° is 
persistent), iff there is some u € L“(M) such that w € prefixes(u) (by the 
first property), iff there is some u € X” such that w € prefixes(w) C £L*(M), 
iff there is some u € &* such that w € prefixes(u) C £*(M)° (because 
prefixes(u) is a persistent safety property), iff w € £*(M)°. 

Finally, the third property is an immediate consequence of the second, 
noticing that M is persistent iff it is equal to M°, and that £*(M) is 
persistent iff it is equal to £*(M)?°. 


Theorem 5 The following hold: 
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Monitorable* = Safety”, 


e Monitorable’ = Safety”, 


Monitorable*” = Safety*”, and 


PersistentMonitorable* = PersistentSafety”. 


Proof: First, note that the following hold for any monitor M: 
e £*(M) € Safety”, 
e £L°(M) € Safety”, and 
e L*”(M) € Safety*”. 


These all follow by Theorem 4: taking P in Definition 12 to be the property 
{w € &* | M(so,w) {}, then OP over finite traces is precisely £*(M), 
over infinite traces is precisely £“(M), and over finite and infinite traces 
is precisely L*”(M), so the three languages are in Safety4, Safety4, and 
Safety*”, respectively. Therefore, Monitorable* C Safety*, Monitorable” C 
Safety”, and Monitorable*” C Safety *”. 

Second, note that we can associate a default monitor Mp to any finite- 
trace property P C b*, namely (Sp,e, Mp: Sp x © — Sp), where Sp = 
prefixes(P), € is the empty word, and Mp(w, a) is defined iff wa € prefixes(P), 
and in that case Mp(w,a) = wa. Moreover, it is easy to check that 


e L*(Mp) = {w € &* | prefixes(w) C P} = OP (over finite traces) , 


e LY(Mp) = {ue dY | prefixes(u) C P} = UP (over infinite traces), 


e L*”*(Mp) = {u € D* Ud” | prefixes(w) C P} = OP (over both finite 
and infinite traces). 


Since P was chosen arbitrarily, it follows then by Theorem 4 that Safety* C 

Monitorable*, Safety” C Monitorable”, and Safety *” C Monitorable*”. 
Finally, the equality PersistentMonitorable* = PersistentSafety* follows 

by the first fact and by Proposition 10. 
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4.2 The Complexity of Monitoring a Safety Property 


We address here the problem of defining the complexity of monitoring. Before 
we give our definition, let us first discuss some pitfalls in defining this notion. 
Our definition for the complexity of monitoring resulted as a consequence of 
trying to avoid these pitfalls. Let P be a safety property. 


Pitfall 1. 


The complexity of monitoring P is nothing but the complexity of 
checking, for an input word w € &*, whether w € prefixes(P). 


This would be an easy to formulate decision problem, but, unfortunately, 
does not capture well the intuition of monitoring, because it does not require 
that the word w be processed incrementally, as its letters become available 
from the observed system. Incremental processing of letters can make a huge 
difference in both how complex monitoring is and how monitoring complexity 
can be defined. For example, it is well-known that the membership problem 
of a finite word to the language of an extended regular expression (ERE), i-e., 
a regular expression extended with complement operators, is a polynomial 
problem (the classic algorithm by Hopcroft and Ullman [8] runs in space 
O(m?-n) and time O(m? - n), where m is the size of the word and n that 
of the expression). However, there are EREs defining safety properties 
whose monitoring requires non-elementary space and time. Of course, this 
non-elementary lower-bound is expressed only as a function of the size of 
the ERE representing the safety property; it does not take into account the 
size of the monitored trace. This leads us to our first guiding principle: 


Principle 1. 


The complexity of monitoring a safety property P should depend 
only upon P, not upon the trace being monitored. 


Indeed, since monitoring is a process that involves potentially unbounded 
traces, if the complexity of monitoring a property P were expressed as a 
function of the execution trace as well, then that complexity measure would 
be close to meaningless in practice, because monitoring reactive systems 
would have unbounded complexity. For example, consider an operating 
system monitoring some safety property on how its resources are being used 
by the various running processes; what one would like to know here is what 
is the runtime overhead of monitoring that safety property at each relevant 
event, and not the obvious fact that the more the operating system runs, 
the larger the total runtime overhead is. 
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Nevertheless, one can admittedly argue that it would still be useful 
to know how complex the monitoring of P against a given finite trace w 
is, in terms of both the size of (some representation of) P and the size of 
w; however, this is nothing but a conventional membership test decision 
problem, that has nothing to do with monitoring. If one picks some arbitrary 
off-the-shelf efficient algorithm for membership testing and uses that at 
each newly received event on the existing finite execution trace, then one 
may obtain a “monitoring” algorithm whose complexity to process each 
event grows in time, as events are processed. In the context of monitoring 
a reactive system, that means that eventually the monitoring process may 
become unfeasible, regardless of how many resources are initially available 
and regardless of how efficient the membership testing algorithm is. What 
one needs in order for the monitoring process to stay feasible regardless 
of how many events are observed, is a special membership algorithm that 
processes each event as received and whose state or processing time does 
not increase potentially unbounded as events are received. Therefore, one 
needs an algorithm which, if it takes resources R to check w, then it takes 
at most R+ A to check a one-event continuation wa of w, where A does not 
depend on w. In other words, one needs a monitor for P of complexity A. 


Pitfall 2. 


P is typically infinite, so the complexity of monitoring P should 
be a function of the size of some finite specification, or represen- 
tation, of P. 


Indeed, since Principle 1 tells us that the complexity of monitoring P is a 
function of P only and not of the monitored trace, one may be tempted to 
conclude that it is a function of the size of some convenient encoding of P. 
There are at least two problems with this approach, that we discuss below. 


e One problem is that the same property P can be specified in many 
different ways as a structure of finite size; for example, it can be 
specified as a regular expression, as an extended regular expression, as 
a temporal logic formula, as an ordinary automaton, as a push-down 
automaton, etc. These formalisms may represent P as specifications of 
quite different sizes. Which is the most appropriate? It is, nevertheless, 
interesting and important to study the complexity of monitoring safety 
properties expressed using different specification formalisms, as a func- 
tion of the property representation size, because that can give us an 
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idea of the amount of resources needed to monitor a particular specifi- 
cation. However, one should be aware that such a complexity measure 
is an attribute of the corresponding specification formalisms, not of the 
specified property itself. Indeed, the higher this complexity measure 
for a particular formalism, the higher the encoding strength of safety 
properties in that formalism: for example, the complexity of monitoring 
safety properties expressed as EREs is non-elementary in the size of the 
original ERE, while the complexity of monitoring the same property 
expressed as an ordinary regular expression is linear in the size of 
the regular expression. Does that mean that one can monitor safety 
properties expressed as regular expressions non-elementarily more ef- 
ficiently than one can monitor safety properties expressed as EREs? 
Of course not, because EREs and regular expressions have the same 
expressiveness, so they specify exactly the same safety properties. All 
it means is that EREs can express safety-properties non-elementarily 
more compactly than ordinary regular expressions. 


e Another problem with this approach is that apparently appropriate 
representations of P may be significantly larger than it takes to monitor 
P. One may say, for example, that, whenever possible, a natural way 
to specify a particular safety property is as a finite-state machine, e.g., 
as a monitor like in Definition 13 . To be more concrete, consider that 
the safety property P, saying “every 2”-th event is a” is specified as a 
monitor of 2” states that transits with any event from each state to 
the next one, except for the 2”-th state, which has only one transition, 
with event a, back to state 1. Therefore, the size of this representation 
of P, is 2(2"). Assuming that each state takes n bits of storage (for 
example, assume that states are exactly the binary encodings of the 
numbers 1, 2, 3, ..., 2”) and that the next state can be calculated from 
the current state in linear complexity with the size of the state (which 
is true in our scenario), then it is clear that the actual complexity of 
monitoring P, is O(n). If the complexity of monitoring P, were a 
function of the size of the specification of P,,, then one could wrongly 
conclude that the complexity of monitoring “every 2”-th event is a” is 


O(2”). 


Therefore, a safety property P has an inherent complexity w.r.t. monitoring, 
complexity which has nothing to do with how P is represented, or encoded, 
or specified. It is that inherent complexity attribute of safety properties that 
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we are after here. From the discussion above, we draw our second guiding 
principle: 


Principle 2. 


The monitoring complexity of a safety property P is an attribute of 
P alone, not a function of the size of some adhoc representation 
of P. 


By Theorem 5, safety properties are precisely those properties that are 
monitorable, that is, those properties P for which there are (finite-state or 
not) monitors M = (S,s9,M:S x % — S) whose (finite-trace, infinite-trace, 
or finite- and infinite-trace—this depends upon the type of P) language 
is precisely P. Any algorithm, program or system that one may come up 
with to be used as a monitor for P, can be organized as a monitor of the 
form M = (S,s9,M:S x & — S) for P. Consequently, the complexity of 
monitoring P cannot be smaller than the functional complexity of the partial 
function M:S x © — S) corresponding to some “best” monitor M for P; if 
there are no additional restrictions, then by “best” monitor we mean the 
one whose functional complexity of M is smallest. In particular, if there 
is no monitor for P whose transition partial function M is decidable, then 
we can safety say that the problem of monitoring P is undecidable. This 
discussion leads to the following: 


Pitfall 3. 


The complexity of monitoring P is the functional complexity of 
function M, where M = (S,s9,M:S x 5% — S) is the “best” 
monitor for P. 


Since safety properties are precisely the monitorable properties, this appears 
to be a very natural definition for the complexity of monitoring. While the 
functional complexity of the monitor function is indeed important because it 
directly influences the efficiency of monitoring, it is not a sufficient measure 
for the complexity of monitoring. That is because the functional complexity 
of M only says how complex M is in terms of the size of its input; it does 
not say anything about how large the state of the monitor can grow in time. 
For example, the rewriting-based monitoring algorithm for EREs from [12], 
whose states are EREs and whose transition is a derivative operation of 
functional complexity O(n?) taking an ERE of size n into an ERE of size 
O(n). It would be very misleading to say that the complexity of monitoring 
EREs is O(n), because it may sound much better than it actually is: the n? 
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factor accumulates as events are processed. Any monitor for EREs, including 
the one based on derivatives, eventually requires non-elementary resources 
(in the size of the ERE) to process a new event. 

Therefore, while the complexity of the function M being executed at 
each newly received event by a monitor M is definitely a necessary and 
important factor to be considered when defining the complexity of monitoring 
using M, it is not sufficient. One also needs to take into account the size of 
the input that is being passed to the monitoring function, that is, the size of 
the monitor state together with the size of the received event. In particular, 
a monitor storing all the observed trace has unbounded complexity, say 
oo, even though its monitoring function has trivial complexity (e.g., the 
“event storing” function has linear complexity). More generally, if a property 
admits no finite-state monitor, than we’d like to say that its monitoring 
complexity is oo: indeed, for any monitor for such a property and for any 
amount of resources R, there is some sequence of events that would lead 
the monitor to a state that needs more than R resources to be stored or 
computed. These observations lead us to the following: 


Principle 3. The complexity of monitoring P is a function of 
both the functional complexity of M and of the size of the states in 
S, where M = (S, 59, M:S x © — S) is an appropriately chosen 
(“best”) monitor for P. 


We next follow the three principles above and derive our definition for 
the complexity of monitoring a safety property P. Before that, let us first 
define the complexity of monitoring a safety property using a particular 
monitor for that property, or in other words, let us first define the complexity 
of a monitor. 

During a monitoring session using a monitor, at any moment in time 
one needs to store at least one state, namely the state that the monitor is 
currently in. When receiving a new event, the monitor launches its transition 
function on the current state and the received input. Therefore, the (worst- 
case) complexity of monitoring with M = (S,s9,M:S x & — S) could be 
defined as 

max{FC(M(s,a)) | s € S,a € 3d}, 


where FC(M(s,a)) is the functional complexity of evaluating M on state 
s and event a, as a function of the sizes of s and a. In other words, the 
worst-case monitoring complexity of a particular monitor is the maximal 
functional complexity that its transition function has on any state and any 
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input; this functional complexity is expressed as a function of the size of the 
pair (state,event). In order for such a definition to make sense formally, one 
would need to define or axiomatize the size of monitor states and the size 
of events. Since in order to distinguish N elements one needs log(N) space, 
we deduce that one needs at least log(|S|) space to store the state of the 
monitor in its worst-case monitoring scenario (each state in S' is reachable). 


Definition 19 Given a monitor M = (S,50,M:S xX — S), we define the 
complexity of monitoring M, written Cyon(M), as the function 


FC(M) (log |S) : NN, 


which is the “uncurried” version applied on log|S| of the worst-case func- 
tional complexity FC(M) : NxN > N of the partial function M as a function 
of the size of the pair (state,event) being passed to it. 


We assume that the complexity of monitoring a safety property P is 
the worst-case complexity of monitoring it using some appropriate, “best” 
monitor for P: 


min{max{FC(M(s,a)) | s€ S,a€ X} | M = (S,s0,M) € Monitors(P)}, 
This gives us the following: 
Definition 20 We let 

Cmon(P) = min{ FC(M) o (log(|S|), 1s) | M = (S, 80, M) € Monitors(P)} 


be the complexity of monitoring a safety property P. 


4.3. Monitoring Safety Properties is Arbitrarily Hard 


We show that the problem of monitoring a safety property can be arbitrarily 
complex. The previous section tells us that there are as many safety prop- 
erties as real numbers. Therefore, it is not surprising that some of them 
can be very hard or impossible to monitor. In this section we formalize 
this intuitive argument. Our approach is to show that we can associate a 
safety property Ps to any set of natural numbers S, such that monitoring 
that safety property is as hard as checking membership of arbitrary natural 
numbers to S. The result then follows from the fact that checking member- 
ships of natural numbers to sets of natural numbers is a problem that can 
be arbitrarily complex. 
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Theorem 1 indirectly says that we can associate a persistent safety 
property to any set of natural numbers (sets of natural numbers are in a 
bijective correspondence with the real numbers). However, it is not clear 
how that safety property looks and neither how to monitor it. We next 
give a more concrete mapping from sets of natural numbers to (persistent) 
safety properties and show that monitoring the property is equivalent to 
testing membership to the set. It suffices to assume that © contains only 
two elements, say © = {0, 1}. 


Definition 21 Let P_ :P(N) > PersistentSafety* be the mapping defined 
as follows: for any S CN, let Pg be the set 1* U{1*0 | k € S}- {0,1}*. 


It is easy to see that Pg is a persistent safety property over finite traces. 
Also, it is easy to see that the bijection in the proof of Theorem 2 associates 
to Pgs the safety property over infinite traces 1” U {1*0 | k € S}- {0,1}¥. 

Let us now investigate the problem of monitoring Ps. 


Proposition 11 For any S CN, monitoring Ps is equivalent to deciding 
membership of natural numbers to S. 


Proof: If Mg is an oracle deciding membership of natural numbers to S, 
that is, if Mgs(n) is true iff n € S, then one can build a monitor for Ps as 
follows: for a given trace, incrementally read and count the number of prefix 
1’s; if no 0 is ever observed then monitor indefinitely without reporting any 
violation; when a first 0 is observed, if any, ask if M(k), where k is the 
number of 1’s observed; if M(k) is false, then report violation; if M(k) is 
true, then continue monitoring indefinitely and never report violation. It is 
clear that this is indeed a monitor for Pg. 

Conversely, if we had any monitor for Ps then we could build a decision 
procedure for membership to S as follows: given k € N, send to the monitor 
a sequence of k ones followed by a 0; if the monitor reports violation then 
deduce that & ¢ S; if the monitor does not report violation, then deduce 
that k € S. It is clear that this is a decision procedure for membership to S. 

The proof works for both persistent safety properties over finite traces 
and for safety properties over infinite traces. 


The claim in the title of this section follows now from the fact that the 
set S' of natural numbers can be chosen so that its membership problem is 
arbitrarily complex. For example, since there are as many subsets of natural 
numbers as real numbers while there are only as many Turing machines as 
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natural numbers, it follows that there are many (exponentially) more sets 
of natural numbers that are not recognized by Turing machines than those 
that are. In particular, there are sets of natural numbers corresponding 
to any degree in the arithmetic hierarchy, i.e., to predicates A(k) of the 
form (Qiki)(Q2k2)+++(Qnkn) R(k, ki, ka,-++, kn), where Qi, Qa, ..., Qn are 
alternating (universal or existential) quantifiers and R is a recursive/decidable 
relation: for A such a predicate, let S4 be the set of natural numbers 
{k | A(k)}. Recall that if Q; is V then A is called a II, property, while if Q, 
is J then A is called a %, property. In particular, %o = Hp and they contain 
precisely the recursive/decidable properties, ©; contains precisely the class 
of recursively enumerable problems, I], contains precisely the co-recursively 
enumerable problems, etc.; a standard Iz problem is TOTALITY: given 
k EN, is it true that Turing machine with Godel number & terminates on all 
inputs? Since each level in the arithmetic hierarchy contains problems strictly 
harder than problems on the previous layer (because ©}, UIT, © Yn4190Un4+1), 
the arithmetic hierarchy gives us a universe of safety properties whose 
monitoring can be arbitrarily hard. 


Within the decidable fragment, as expected, monitoring safety proper- 
ties can also have any complexity. Indeed, pick for example any NP-complete 
problem and let S be the set of inputs (coded as natural numbers) for 
which the problem has a positive answer; then, as explained in the proof 
of Proposition 11, monitoring Pg against input 1*0 is equivalent to decid- 
ing membership of & to S, which is further equivalent to answering the 
NP-complete problem on input k. Of course, in practice a particular (im- 
plementation of a) monitor can be more complex than the corresponding 
membership problem; for example, monitors corresponding to NP-complete 
problems are most likely exponential. Also, note that a monitor for Ps needs 
not necessarily do its complex computation on an input 1*0 when it encoun- 
ters the 0. It can perform intermediate computations as it reads the prefix 
1’s and thus pay a lesser computational price when the 0 is encountered. 
What Proposition 11 says is that the total complexity to process the input 
1*0 can be no lower than the complexity of checking whether k € S. 


4.4 Canonical Monitors 


We conclude this section with an alternative definition of a monitor, called 
canonical monitor, which is more compact than our previous definition and 
which appears to be sufficient to capture any safety property. We do not 
make any use of this alternative definition in this paper, but it may serve as 
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a basis for further foundational endeavors in this area. 

The set of states S of a monitor (S, 59, M:S xX — S) are typically enu- 
merable, so they can very well be replaced with natural numbers. Moreover, 
the initial state sg can be encoded, by convention, as the first natural number, 
0. A monitor then becomes nothing but a partial function N x = — N. We 
therefore rightfully call these particular monitors canonical: 


Definition 22 A canonical /-monitor is a partial function N:N x UN. 
Let Sy = {n | (dw) N(0, w) = n} be the states of N. As before, let 


e L*(N) = {w € d* | N(0,w) Lf, 
e L°(N) = {ue &* | N(0,w) | for all w € prefixes(u)}, and 
0 LYN) = LI(N)ULY(N). 


Although the set of states S in a monitor (S,59,M:S x © — S) is 
allowed to have any cardinal while the states in canonical monitors are 
restricted to natural numbers, it turns out that canonical monitors can in 
fact express all monitorable properties: 


Proposition 12 A property P C &* (resp. P CS”, resp. P € S* UX”) 
is monitorable iff there is some canonical monitor N such that P = L*(N) 
(resp. P= LON 5 resp. P= LION: 


Proof: Since any canonical monitor is a monitor, it follows that any 
property specifiable by a canonical monitor is indeed monitorable. For 
the converse, let P be a property monitorable by some monitor M = 
(S, 50, M:S xX — S). Since |X| < No, we can enumerate all the states of M 
that can be reached from sg with its transition function M. There are many 
different ways to do this (e.g., in breadth-first order, in depth-first order, 
etc.), but these are all ultimately irrelevant. If we let S” = {50, 51, 52,...} 
denote the resulting set of reachable states, then it is easy to first note that 
the monitor M" = (S", so, M:S" x © — S") specifies the same property P 
as M, and second note that M” specifies the same property as the canonical 
monitor V:N x © — N defined by N(i, a) = 7 iff M(s;,a) = 5;. 


5 Conclusion 


This paper presented a comprehensive study of safety properties and of 
their monitoring, using a uniform formalism and notation. Technically, the 
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paper made two novel contributions. First, it introduced the notion of 
a persistent safety property, which is the finite-trace correspondent of an 
infinite-trace safety property, and used it to show the cardinal equivalence of 
the various notions of safety property encountered in the literature. Second, 
it rigorously defined the problem of monitoring a safety property, and it 
showed that it can be arbitrarily hard. We believe that this paper establishes 
a firm foundation for studying safety properties, as well as corresponding 
monitors and algorithms for various domains of interest, where requirements 
can be expressed using domain-specific formalisms, such as future-time and 
past-time temporal logics, context-free grammars, push-down automata, and 
so on. 
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